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INTERNET OVER SATELLITE METHOD 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

The following three commonly -owned co-pending 
applications, including this one, are being filed concurrently 
and the other two are hereby incorporated by reference in 
their entirety for all purposes: 

1. U.S. Patent Application Serial No. 60/118,227, in the 
name of Jerome D. Toporek et. al., titled, "Internet 
Over Satellite Apparatus"; 

2. U.S. patent application Sen No. 09/243,185, in the 
name of Jerome D. Toporek et. al., titled, "Internet 
Over Satellite System"; 

3. U.S. patent application Ser. No.09/243,554, in the name 
of Jerome D. Toporek et. al., titled, "Internet Over 
Satellite Method". 

BACKGROUND OF THE INVENTION 

The present invention relates to telecommunication tech- 
niques. More particularly, the present invention provides a 
technique including a method for transmitting information 
using a TCP connection over a satellite system for use in a 
wide area network of computers such, as the Internet. The 
present method provides a high speed and quality transmis- 
sion of signals to a distant location over a satellite system 
using an Xpress Transport Protocol (herein "XTP") 
protocol, for example. But it will be recognized that the 
invention has a much wider range of applicability; it can also 
be applied to a private bridged network, terrestrial wireless 
network links, and the like. 

The Internet is an international "super-network" connect- 
ing together millions of individual computer networks and 
computers. The Internet is generally not a single entity. It is 
an extremely diffuse and complex system over which no 
single entity has complete authority or control. Although the 
Internet is widely known for one of its ways of presenting 
information through the World Wide Web (herein "Web"), 
there are many other services currently available based upon 
the general Internet protocols and infrastructure. 

The Web is generally easy to use for people inexperienced 
with computers. Information on the Web can be presented on 
"pages" of graphics and text that contain "links" to other 
pages either within the same set of data files (i.e., Web site) 
or within data files located on other computer networks. 
Users often access information on the Web using a 
"browser" program such as one made by Netscape Com- 
munications Corporation of Mountain View, Calif, or 
Microsoft Corporation of Redmond, Wash. Browser pro- 
grams process information from Web sites and display the 
information using graphics, text, sound, and animation. 
Accordingly, the Web has become a popular medium for 
advertising goods and services directly to consumers. 

The Internet supports many other forms of communica- 
tion. For example, the Internet allows one-to-one commu- 
nication via electronic mail, which is commonly known as 
"e-mail." The Internet also has "bulletin boards" which are 
used by users to post colorful text and graphics for others to 
read and respond to. For real time communication, the 
Internet has "chat rooms" and the like, which allow users to 
communicate to each other by way of typed messages. In 
some cases, the Internet can also be used for voice commu- 
nication between users. All of these forms of communication 
are possible, at least in part, by way of an important 
connection, which allows information to be transmitted from 
many different servers on the Internet. 



54,083 Bl 

2 

The Internet is based on the TCP/IP protocol suite. At the 
network layer, an Internet Protocol, which is known as IP, 
provides a mechanism to deliver packets addressed to indi- 
vidual computers. The Internet has a plurality of computer 

5 systems implementing IP, which are generally intercon- 
nected to each other using local area networks and dedicated 
transmission lines, to form a wide area network of comput- 
ers. IP packets are delivered on a best effort basis and are not 
guaranteed to arrive at their intended destination, which is 

10 known as "unreliable" service. 

For many applications that require reliable data delivery 
service, the Internet uses a connection mechanism called 
Transmission Control Protocol, which is known as TCP 
TCP has a variety of desirable characteristics that allows it 

15 to be suitable for communication over the Internet. For 
example, TCP considers the data size or best sized segment 
of data to send from a transmitting server over the commu- 
nication medium to a receiving server. Additionally, TCP 
maintains a timer, which waits for the receiving server to 

20 send an acknowledgment of the reception of the data seg- 
ment from the transmitting server. If the timer times out 
before the acknowledgment is received, TCP resends the 
data segment, which provides reliability in the communica- 
tion. TCP also maintains a checksum on its header and data, 

25 which monitors any modification in the data in transit. If the 
data arrives with an invalid checksum, TCP discards the data 
and does not acknowledge receiving the data. If data seg- 
ments arrive out of order, TCP can also recombine the 
segments in order at the receiving server. Furthermore, TCP 

30 provides flow control, which only allows a finite amount of 
data to be sent to a buffer on the receiving server. This 
prevents a fast server computer from overflowing all the 
buffers on a slower server computer. 
Although TCP has been well suited for transmitting 

35 Internet data between a plurality of servers, which are 
coupled to each other by way of conventional telephone 
systems and lines with similar characteristics, TCP has many 
limitations. For example, TCP is suitable for "short hops" 
but often slows down communication over extremely long 

40 distances which can have significant latency (e.g., transcon- 
tinental hops via satellite). Here, the flow control and 
acknowledgment features take too long to send and receive, 
which make communication slow. Additionally, opportuni- 
ties for gains in efficiency still exist. In particular, TCP has 

45 been found to be slow and cumbersome for transmission of 
Internet data over a satellite network, for example. 
Additionally, networking using satellites often encounters 
significant bit error rates, which leads to further slowing of 
TCP connections. These and other limitations will be more 

50 fully described according to the Figs, below. 

From the above, it is seen that a more efficient way of 
transporting Internet services over large geographical 
regions using wireless communication media is highly desir- 

55 abk * 

SUMMARY OF THE INVENTION 

According to the present invention, a technique for 
improving TCP performance over a wireless wide area 

60 network is provided. In an exemplary embodiment, the 
present invention provides a method for converting infor- 
mation using a TCP connection to an Xpress Transport 
Protocol (herein "XTP") connection, for example, which is 
more suitable for transmission over a wireless network 

65 system such as a satellite system. 

In a specific embodiment, the present invention provides 
a communication method for transmitting information over 
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a satellite link. The method includes providing a 
bi-directional flow of information, which has data and a 
header, using a TCP connection. As merely an example, the 
bi-directional flow of information can be from the Internet or 
internet-like network of computers or any network using 5 
TCP/IP protocols. The method also includes converting the 
information, using the TCP connection, into a satellite 
protocol for transmission over a satellite link. The satellite 
protocol has suitable characteristics for transmission of such 
information over a satellite link. The protocol can include, 10 
among others, XTP, XTP-like protocols, and the like. 

In an alternative embodiment, the present invention pro- 
vides a communication method for establishing a plurality of 
connections for transmission of information using a TCP 
connection over a satellite link. The method includes inter- 15 
cepting a first communication connection between a first 
client (e.g., user computer) to a first satellite gateway. The 
method also includes forming a second communication 
connection between the first satellite gateway to a second 
satellite gateway that is over a satellite link. Information 20 
describing characteristics (e.g., source and destination IP 
addresses and port numbers) of the first connection is 
transmitted to the second satellite gateway. A third commu- 
nication connection is formed between the second satellite 
gateway and the destination server. A combination of these 25 
connections forms a transparent connection from the origi- 
nal first client to the destination server. 

In another aspect of the present invention, techniques for 
matching a data rate for information flowing through a 
predetermined point in a network, such as a satellite, to the 30 
data rate capabilities of a remote point on the network are 
provided. In one embodiment, the present invention pro- 
vides rate control to maintain a suitable or predetermined 
data rate over the satellite device. The rate control provides 
a plurality of queues for buffering incoming data. Incoming 35 
data are checked against a predetermined length. Data in 
excess of the predetermined length are stored in the queues. 
At predetermined intervals, information is taken from one or 
more queues and transmitted along the outgoing data path. 
This processing can enable systems according to the present 40 
invention to provide for data rate control across a particular 
point of interest along the network, such as a satellite link. 

Numerous benefits are achieved by way of the present 
invention over conventional techniques. In a specific 45 
embodiment, the present invention provides a higher 
throughput than conventional systems. Additionally, the 
present invention provides for a way to transparently 
improve TCP performance over a satellite network. In other 
embodiments, the present invention provides for a novel 5Q 
protocol which is suitable for long latency, high loss, asym- 
metric bandwidth conditions, which are typical of satellite 
communications. The present invention also provides for 
relatively easy implementation into a conventional satellite 
system. Depending upon the embodiment, one or more of S5 
these benefits can be present. These and other advantages or 
benefits are described throughout the present specification 
and are described more particularly below. 

These and other embodiments of the present invention are 
described in more detail in conjunction with the text below 60 
and attached Figs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a simplified diagram of a satellite system 
according to an embodiment of the present invention; es 

FIGS. 2 and 2A are simplified diagrams of system archi- 
tectures according to embodiments of the present invention; 
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FIGS. 3A-3E are simplified diagrams of process dia- 
grams according to embodiments of the present invention; 
and 

FIGS. 4-6 are simplified diagrams of experimental data 
according to embodiments of the present invention. 

DESCRIPTION OF THE SPECIFIC 
EMBODIMENTS 

Before discussing the various embodiments, it may assist 
the reader to more fully understand the limitations of using 
TCP over a satellite network. Some of these limitations are 
described more fully below. 

Congestion Avoidance: In order to avoid the possibility of 
congestive network meltdown, TCP generally assumes 
that all data loss is caused by congestion and responds 
by reducing the transmission rate. Over satellite links, 
however, TCP often misinterprets the long round trip 
time and bit errors as congestion and responds inap- 
propriately. Similarly, the TCP "Slow Start" algorithm, 
which over the terrestrial infrastructure prevents new 
connections from flooding an already congested 
network, over satellites forces an excessively long 
ramp-up for each new connection. While these conges- 
tion avoidance mechanisms are important in routed 
environments, they are often ill-suited to satellite links. 

Data Acknowledgments: The simple, heuristic data 
acknowledgment scheme used by TCP generally does 
not adapt well to long latency or highly asymmetric 
bandwidth conditions. To provide reliable data 
transmission, the TCP receiver often constantly sends 
acknowledgments for the data received back the sender. 
The sender generally does not assume any data is lost 
or corrupted until a multiple of the round trip time has 
passed without receiving an acknowledgment. If a 
packet is lost or corrupted, TCP can retransmit all of the 
data starting from the first missing packet. The algo- 
rithm may not respond well over satellite networks 
where the round trip time is long and error rates are 
high. Further, the constant stream of acknowledgments 
frequendy wastes precious back channel bandwidth. If 
the back channel bandwidth is small, the return of the 
acknowledgments to the sender can become the system 
bottleneck in some cases. 

Window Size: TCP utilizes a sliding window mechanism 
to limit the amount of data in flight. When the window 
becomes substantially full, the sender stops transmit- 
ting data until it receives new acknowledgments from 
the destination server. Over satellite networks, where 
acknowledgments are slow to return, the TCP window 
size generally sets a hard limit on the maximum data 
throughput rate. The minimum window size often 
needed to fully utilize an error-free link, known as the 
"baodwidth-delay product/' is 100 Kbytes for a Tl 
satellite link and 675 Kbytes for a 10 MBps link, for 
example. Bit errors can increase the required window 
size further. However, most implementations of TCP/IP 
are often limited to a maximum window size of 64 KB 
and many common operating systems use a default 
window size of only 8 KB, imposing a maximum 
throughput rate over a satellite link of only 128 Kbps 
per connection, regardless of the bandwidth of the data 
pipe. 

According to the present invention, a technique for pro- 
viding a TCP connection over a wide area wireless network 
is provided. In an exemplary embodiment, the present 
invention provides a method for converting information 
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using a TCP connection to an XTP connection, which is described here without departing from the scope of the 

more suitable for transmission over a wireless network present invention, 

system such as a satellite system. Details of the present Additionally, the present satellite gateway is generally 

method are described throughout the present specification described as a stand alone unit. It will be recognized, 

and more particularly below. 5 however, that the present gateway can be implemented or 

FIG. 1 is a simplified diagram of a satellite system 100 integrated into a client machine. For example, the present 

according to an embodiment of the present invention. This gateway can be implemented on a personal computer using 

diagram is merely an illustration and should not limit the a satellite card, which can be inserted into a Windows™ 98 

scope of the claims herein. One of ordinary skill in the art machine. The present gateway can also be implemented on 

would recognize other variations, modifications, and alter- 10 other operating systems such as Windows NT, MacOS, and 

natives. Among other features, the system 100 includes a Linux. Of course, the exact manner of implementation will 

satellite network system, which has satellite(s) 101. The depend upon the application. 

satellite 101 receives and transmits information between a Additionally, the present satellite gateway may be inte- 

plurality of ground stations 107, 108 or satellite dishes. Each grated into a standalone satellite modem, VSAT hardware, 

satellite ground station includes a satellite dish, and a 15 router or other network devices, 

satellite modem 109 A, 109B or other form of receiver such I. Protocol Design 

as a VSAT indoor unit, which is coupled, directly or indi- In a specific embodiment, the present method includes a 
rectly to a satellite gateway 111A, 111B. novel satellite protocol, which provides improved through- 
Satellite antenna 108 receives and transmits signals 103 put for satellite networks. The present protocol can be 
through satellite 101. Satellite antenna 108 connects to 20 designed to respond efficiently to typical satellite latency, bit 
satellite gateway 111B that couples to a wide area network errors, and asymmetric bandwidth conditions. The present 
such as the Internet 129 or an internet, which is coupled to protocol also can take advantage of optimizations possible 
a server 131. The gateway 111B also couples through on a point-to-point link with fixed bandwidth. For further 
satellite modem 109B. The server and the Internet commu- information regarding satellite protocols, such as XTP, ref- 
nication occur in a common protocol such as TCP/IP, 25 erence may be had to Tim Strayer, "A Brief Introduction to 
UDP/IP or the like. The satellite gateway will be described the Xpress Transport Protocol " which is incorporated herein 
in more detail below. by reference in its entirety for all purposes. These and other 
Satellite antenna 107 receives and transmits signals 105 features of the present satellite protocol are described in 
through satellite 101. Satellite antenna 107 connects to more detail below. 

satellite gateway 111 A that couples to a local area network 30 The present protocol utilizes an efficient selective retrans- 

such as Ethernet, Token Ring, FDDI, or others 121, which mission algorithm for the acknowledgment of data. Because 

is coupled to computer terminals 123 or clients. Here, the hop over the satellite is a point-to-point link with no 

satellite gateway couples to laptop 117, which is coupled intermediate routing, any gaps in the packet sequence can be 

through modem 119. The client, the laptop, and the local assumed to be data loss due to corruption. The receiving 

area network use a common connection format such as 35 satellite gateway requests retransmission immediately upon 

TCP/IP, IPX/SPX, or the like. The satellite gateway will be detection of the missing data from the transmitting satellite 

described in more detail below. gateway. 

In a specific embodiment, satellite gateway 111A inter- The present protocol is substantially free from the fre- 

cepts a TCP connection from a client and converts data 105 quent acknowledgment features of conventional TCP. In 

to a satellite protocol for transmission over satellite 101. The 40 some embodiments, the present protocol does not use 

gateway 111 A also couples through satellite modem 109 A, acknowledgments as the primary means of identifying lost 

which transmits data to satellite 101. The satellite gateway data. In these embodiments, the present protocol needs only 

111B on the opposite side of the satellite link translates the infrequent acknowledgments to confirm data arrival and 

data in the satellite protocol back to TCP for communica- clear buffers. (Conventional TCP sends a constant stream of 

lions with the server 131. In a specific embodiment, the 45 acknowledgments over the reverse channel.) The present 

present method provides improved performance over con- protocol reduces back channel usage by 70% or more, 

ventional techniques. Additionally, the present method thereby increasing the performance of networks where lim- 

remains substantially transparent to an end user and is fully ited back channel bandwidth is the system bottleneck, 

compatible with the Internet or an internet infrastructure, In The present protocol offers adequately large window sizes 

many, if not all aspects, no substantial changes are required 50 for transmission of data between the satellite gateways, 

to the client or server. In preferred embodiments, applica- Because the bandwidth -delay product over the satellite 

tions continue to function without substantial hardware between the satellite gateways is much larger than that from 

and/or software modifications. the satellite gateway to the end node, the large present 

Although the above has been described in terms of a protocol window enables the bandwidth-delay product to 

specific networking diagram, it is possible to implement the 55 window size ratio to remain relatively constant. The present 

present satellite gateway in other configurations. For gateway becomes a buffer for the network, allowing high 

example, the present satellite gateway can be one "hub" or throughput independent of the window size of the clients 

central gateway that serves a plurality of remote gateways. and servers. 

Each of the remote gateways is connected to the central The present protocol generally does not use unnecessary 
gateway to create an individual satellite link. eo congestion avoidance mechanisms for the hop over the 
Other common network topologies can also be used. satellite between the satellite gateways. The present system, 
Further, in some embodiments, different telecommunica- however, continues to use "Slow Start" and all other stan- 
nous links can be used to carry forward and backward paths dard TCP congestion avoidance algorithms for the terrestrial 
of a connection. For example, a satellite link can be used to connections between the present gateways and the end 
carry data on the forward path, while telephone line can be 65 nodes. The present protocol also uses a streamlined hand- 
used for the backward path. Other types of telecommunica- shake mechanism to reduce the number of round-trip times 
tions hardware may be substituted for the example hardware required for connection set-up. 
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The present method can run over IP for compatibility with correctness is done via error control algorithms and main- 

routed networks. Alternatively, it can run directly over the tenance of a connection state machine. Flow and rate control 

link layer for substantially improved performance in most algorithms, certain protocol modes, and traffic shaping info r- 

instances. Depending upon the embodiment one or more of mation are used to provide the requested quality of service 

these features can be available. 5 as efficiently as possible. 

The above has generally been described in terms of The collection of information comprising the XTP state at 

desirable features of the present satellite protocol. It would an end system is called a context. This information repre- 

be recognized that many other types of features can be sents one instance of an active communication between two 

available. Additionally, the present invention does not nec- (or more) XT? endpoints. A context should be created, or 

essarily require each of the above features. Any combination 10 instantiated, before sending or receiving XTP packets. There 

can be used depending upon the application. One of ordinary may be many active contexts at an end system, one for each 

skill in the art would recognize other variations, active conversation or message. 

modifications, and alternatives. Each context manages both an outgoing data stream and 

H. Xpress Transport Protocol an incoming data stream. A data stream is an arbitrary length 

In a preferred embodiment, the present invention provides 15 string of sequenced bytes, where each byte is represented by 

an "Xpress Transport Protocol," which is commonly known a sequence number. The aggregate of a pair of active 

as XTP. XTP provides orthogonal protocol functions for contexts and the data streams between them is called an 

separation of implementation from policy, separation of rate association. 

and flow control, explicit first-class support for multicast, A context at an end system is initially in a quiescent state, 

and data delivery service independence. XTP has a variety 20 A user in need of communication services requests that the 

of suitable characteristics for transmission of data over a context be placed into the listening state. The context now 

satellite link, which are described more fully below. listens for an appropriate FIRST packet. The FIRST packet 

In a specific embodiment, the present protocol includes a is the initial packet of an association. It contains explicit 

set of mechanisms whose functionality is orthogonal. The addressing information. The user should provide all of the 

most notable effect of this is that XTP separates communi- 25 necessary information for XTP to match an incoming FIRST 

cation mechanism (e.g., data -gram, virtual circuit, packet with the listening context. 

transaction, etc) from an error control policy employed At another end system a user requests communication 

(fully reliable through uncorrected). Further, flow and rate service from XTP. Since this user will initiate the 

control as well as error control can be tailored to the association, the context moves from a quiescent state to an 

communication at hand. If desired, any set of these control 30 active state directly. The active context constructs a FIRST 

procedures can be turned off. packet, complete with explicit addressing information from 

The present protocol also provides for separation of rate the user. The FIRST packet is sent via the underlying data 

and flow control. In general, flow control operates on delivery service. 

end-to-end buffer space. Rate control is a producer/ When the FIRST packet is received at the first host's XTP 

consumer concept that considers processor speed and con- 35 implementation, the address is compared against all listen- 

gestion. TCP does not provide rate control, and combats ing contexts. If a match is found, the listening context moves 

congestion with slow-start and other heuristics. XTP pro- to the active state. From this point forward an association is 

vides mechanisms for shaping rate control and flow control established, and communication can be completely symmet- 

independently. ric since there are two data streams, one in each direction, in 

In a specific embodiment, the present protocol provides 40 an association. Also, no other packet during the lifetime of 

explicit multicast support. Here, multicast is not an after- the association will carry explicit addressing information, 

thought in XTP. Each mechanism used for uni-cast commu- Rather, a unique "key" is carried in each packet that maps 

nications is available for multicast use as well. the packet to the appropriate context. 

The present protocol also has data delivery service inde- Once all data from one user has been sent, that data stream 

pendence. In particular, XTP is a transport protocol, yet with 45 from that user's context can be closed. Sentinels in the form 

the advent of switched networks rather than routed of options bits in a packet are exchanged to gracefully close 

networks, a traditional network layer service may not be the connection. Other forms of less graceful closings are 

appropriate in every instance. XTP generally requires that possible by abbreviating this exchange. When both users are 

the underlying data delivery service provides framing and done, and both data streams closed, the contexts move into 

delivery of packets from one XTP -equipped host to another. 50 the inactive state. One of the contexts will send a sentinel 

This could be raw MAC or IP or AAL5. XTP also employs that causes the association to dissolve. At this point, both 

parametric addressing, allowing packets to be addressed contexts return to the quiescent state, 

with any one of several standard addressing formats. Other Generally all of XTP's packet types use a common header 

features of XTP include, among others, implicit fast con- structure. All of the information necessary to steer the 

nection setup for virtual circuit paradigm; key-based 55 packet's payload to the proper point of processing is carried 

addressing lookups; message priority and scheduling; sup- in the header. Much of how an XTP context operates is 

port for encapsulated and convergence protocols; selective controlled by a set of bit flags that are concentrated in one 

retransmission and acknowledgment; and fixed-size 64-bit field in the packet header. Fifteen flags are defined, including 

aligned frame design. bit flags to control connection shutdown, bit flags to control 

XTP defines the mechanisms necessary for delivering 60 the acknowledgment policy, and bit flags that are markers in 

user data from one end system to one or more other end the data stream. The remaining bit flags control the end-to- 

systems. Each XTP implementation maintains the state of end operating modes. Examples include enabling or dis- 

each of its communications. Well-defined packet structures, abling error control or flow control, or enabling multicast 

containing user data or control information, are exchanged mode. 

in order to effect the user data transfer. The control infor- 65 XTP flow control is based on 64-bit sequence numbers 

mation is used to provide the requested layer of correctness and a 64-bit sliding window. XTP also provides rate control 

and to assist in making the transfer efficient. Assurance of whereby an end system or intermediate system can specify 
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the maximum bandwidth and burst size it will accept on a 
connection. A Traffic Segment provides a means for speci- 
fying the shape of the traffic so that both end systems and 
intermediate systems can manage their resources and facili- 
tate service quality guarantees. 5 

Error control in XTP incorporates positive and, when 
appropriate, negative acknowledgment to effect retransmis- 
sion of missing or damaged data packets. Retransmission 
may be either go-back-N or selective. The retransmission 
algorithms are conservative: only data that is shown to be 10 
missing via control messages may be transmitted. This 
avoids spurious and possible congestion-causing retransmis- 
sions. The error control algorithm, while basically 
conservative, can also be aggressive: a method for a quick- 
acting error notification is provided. 15 

XTP also specifies techniques for extending error control 
to a multicast environment. The error control algorithm in 
multicast is identical to the uni-cast algorithm, although 
additional sophistication is required to manage state vari- 
ables and achieve continuous streaming. Accordingly, XTP 20 
is a preferred satellite protocol according to the present 
invention. 

Although the above has generally been described in using 
an XTP protocol, it will be understood that other types of 
protocols can be used. For example, the protocol can be a 25 
modified TCP, a modified XTP, and others. Additionally, the 
protocol can be any that is suitable for transmission over a 
satellite link. Additionally, one of ordinary skill in the art 
would recognize other variations, modifications, and alter- 
natives. 30 

FIG. 2 is a simplified diagram of system architecture 200 
according to an embodiment of the present invention. This 
diagram is merely an illustration and should not limit the 
scope of the claims herein. One of ordinary skill in the art 
would recognize other variations, modifications, and alter- 35 
natives. The system architecture 200 includes at least a client 
201, which is coupled to a satellite gateway 203, which 
transmits and receives information via satellite link 209 
from a satellite gateway 205. Satellite gateway 205 couples 
to server 207. Satellite gateway and server couple to each 40 
other through the Internet or an internet-like network of 
computers. 

Client 201 can be represented in multiple layers, includ- 
ing application-and physical layers. The layers may include 
a browser 211. The browser 211 allows a user to commu- 45 
nicate information from an application layer to a physical 
layer for transmission to a gateway. The browser 211 is 
generally in the application layer, which provides the infor- 
mation. For example, the browser can be one of suitable 
design made by a company called Netscape Communica- 50 
tions Corporation of Mountain View, Calif, or Microsoft 
Corporation of Redmond, Wash, or others. In addition to 
browsers, other TCP applications, including FTP file 
transfers, may also be used to communicate between clients 
and servers. 55 

The information goes through the transport layer (e.g., 
TCP) 213 and then through the IP layer 215, which is the 
networking layer. The transport layer provides a flow of data 
between the client and the gateway. The IP layer handles 
movement of data comprising packets between the client 60 
and the gateway, or other network. The information is sent 
through the physical layer, which includes a driver 217. The 
driver 217 transmits the information to the gateway 203 
through hardware 219 connected to gateway 203 via a 
telecommunications link 221, which can be a wire, cable, 65 
fiber optic, or other physical communication medium. 
Alternatively, the driver 217 receives information from the 
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gateway 203 via link 221 and hardware 219. The driver can 
be a network operating system with a network interface card 
in the client computer, for example. 

From the physical connection 221, the information 
traverses to the gateway 203. The gateway has a physical 
layer 223, which interacts with driver 225. The gateway also 
includes a networking layer 227 and a transport layer 229, 
which is coupled to a translation module 231. The network- 
ing layer 227 determines whether the information can be 
routed over the satellite protocol. If so, the data is passed up 
to the transport layer 229. If not, the data is immediately 
forwarded out to the rate control module 234 for delivery to 
the satellite link 239 in non-translated form. The translation 
module 231 converts the information into a satellite protocol 
233, which is suitable for use over a satellite link. A rate 
control module 234 determines whether the information can 
be passed immediately to the satellite connection or be 
queued for later delivery. The satellite connection is coupled 
to a physical layer 237 by a driver 235, which transmits 
information to and from satellite 209. The information 
traverses to and from the satellite in a wireless medium, 239, 
241. 

Information is received by the satellite gateway 205, 
which includes multiple, layers, physical and others. The 
physical layer 243 couples to driver 245. The networking 
and transport layer include a satellite protocol 247 and a rate 
control 244. The network and transport layers connect to a 
session layer which comprises translation module 249. The 
translation module converts the information using the sat- 
ellite protocol back to TCP/IP. The information traverses 
through the transport layer (i.e., TCP) 251 and the network- 
ing layer (i.e., IP) 253. Information from the satellite gate- 
way 205 enters a physical layer 257 through driver 255. The 
driver transmits the information to a server 207 over tele- 
communications link 259. Driver 255 can also receive 
information from server 207 in the backward path. 

From the telecommunications link 259, the information is 
sent to driver 263 in the server 207 via physical layer 261, 
The information traverses from the driver to a networking 
layer, which includes IP 265. The information also traverses 
from the networking layer to a transport layer, which 
includes TCP 267. The information is delivered to a Web 
server application 269, for example. Between the server 207 
and the satellite gateway 205 is the Internet or, another IP 
network, depending upon the application. 

In a specific embodiment, information can flow through a 
gateway, such as gateway 203, 205 at the network layer, 
bypassing the transport and application layers altogether. 
For example, in gateway 203, information can enter from 
client 201 via telecommunications link 221. Physical layer 
223 passes the information to driver 225. In turn, driver 225 
passes the information to network layer 227. Network layer 
227 can route the information to its destination using IP. The 
information then flows from network layer 227 to driver 
235. Driver 235 interacts with physical layer 237 to pass the 
information along to satellite 209 via telecommunications 
link 239. 

In a specific embodiment, the translation module converts 
information using a TCP connection to a suitable connection 
for transmission over a satellite system. The suitable con- 
nection for the satellite is generally resilient to transmission 
over a wireless network such as a satellite network, e.g., 
Orion Worldcast™ PanAmSat™ Spotbytes™ services, and 
the like. The connection should also be suitable for long 
latency, high loss, and asymmetric bandwidth conditions. 
The connection should also be transparent to the end user at 
the client or server location. The long latency is typically 
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about 200 milliseconds to about 700 milliseconds per sat- over a wireless (e.g., satellite) link. The connection between 

ellite hop but is not limited to such values. the wireless link can be any suitable connection such as XTP 

In a specific embodiment, the present translation module or XTP- like connection. The present process provides a third 

converts information using a TCP connection into an XTP, connection, step 307, which forms a TCP connection 

modified TCP or XTP- like protocol for transmission over a 5 between the destination gateway to the destination server, 

satellite link, which is illustrated by FIG. 2A, for example. which can traverse through the Internet or an internet. Once 

Here, the TCP module receives information 350 including these connections have been made they are maintained, step 

the TCP connection. The information includes data 333, a 309. The present process ends at stop 311, which terminates 

TCP header 335, and an IP header 337. The TCP module all three connections. 

removes the TCP header from the information such that the 10 In a specific embodiment, the present process occurs by 
information 351 includes substantially all data 333 and way of a selected sequence of steps. Here, TCP SYN packets 
passes the data, along with certain TCP header information, are intercepted transparently by a satellite gateway. The 
to the translation module. The translation module passes the satellite gateway establishes a new XTP connection across 
data or portions of data to the satellite protocol module the satellite link to the other satellite gateway. Information, 
where a satellite protocol header 339 is prepended onto the 15 including IP addresses and port numbers, about the request- 
data. The header is an XTP header or like. The information ing client and the destination server is transferred across the 
352 now includes the XTP header, which is suitable for satellite link to the other satellite gateway. The destination 
transmission over the satellite link. Depending on the spe- gateway then sets up a TCP connection with the destination 
cific implementation, the XTP header and data may also be server, using the client's addressing information so that the 
prepended with an IP header for transmission over the 20 server sees the TCP connection as being the same as if the 
satellite link. In particular, the information is transferred to client itself had established the connection. The satellite 
the physical layer and the driver. The driver and physical gateway makes routing decisions based upon source and 
layer send the information to a receiving satellite gateway, destination addresses in the IP header of packets entering the 
which may prepend additional headers. gateway in order to determine whether the packets should be 

From the satellite link, the information including the XTP 25 routed over the satellite telecommunications link. Once the 

header enters a receiving XTP module. The receiving XTP TCP connection to the server is established, the destination 

or satellite protocol module removes the XTP header from gateway communicates back to the sending gateway, which 

the information, leaving data 353. Hie receiving satellite then acknowledges the connection with the client, 

protocol module passes the data to the translation module, In one or more embodiments, this sequence of steps has 

which can be a routing module used to route data to the 30 advantages. In particular, the client does not believe the 

proper protocol. The translation module then passes the data connection is established until the server has accepted this 

to the TCP module. The receiving TCP module attaches a connection, which tends to reduce or even eliminate false 

TCP header 343 and IP header 341 onto the data to form indications of successful connection establishment, 

information that is now ready for transmission over a Additionally, both the client and server see the connection as 

network to a receiving server destination. The information 35 happening immediately between the two of them, without 

using the TCP connection traverses through a network to the detecting that the satellite connection is happening in 

destination server. between the client and the server. That is, the present 

In other embodiments, the translation module can also invention substantially preserves "end-to-end semantics" of 

convert a portion of the information including the data and the connection. In other embodiments, the connectivity is 

TCP/IP headers to information using the XTP protocol. 40 symmetric. Here, "clients" may exist on either side of the 

Alternatively, the translation module can convert more than satellite link, and "servers" may exist on either side. Systems 

one segment of information including multiple TCP/IP on either side may request connections to systems on the 

headers into a single piece of information including the XTP other side, and the satellite gateways will intercept the 

header for transmission over a satellite link. Depending connections. 

upon the application, the translation module can convert the 45 FIG. 3B illustrates a simplified flowchart of a novel 

information including the TCP connection into any one or routing process 320 in a specific embodiment according to 

any combination of the above. Further details of these the present invention that begins with a starting step 321, 

methods, and others, are described in more detail below. This diagram is merely an example which should not limit 

FIGS. 3 A and 3B are simplified diagrams of process the scope of the claims herein. One of ordinary skill in the 

diagrams according to embodiments of the present inven- 50 art would recognize other variations, modifications, and 

tion. These diagrams are merely illustrations and should not alternatives. In a step 323, a client host sends a TCP packet 

limit the scope of the claims herein. One of ordinary skill in destined for a particular IP address to a satellite gateway. In 

the art would recognize other variations, modifications, and an example, the satellite gateway can be similar to the one 

alternatives. In a specific embodiment, the present invention 111 A described above, but can also be others. In a decisional 

uses a connection process 300, which is illustrated by FIG. 55 step 325, the satellite gateway receives the packet and 

3A. The connection process uses a plurality of separate determines whether the packet is to be carried over an XTP 

connections using a "handshaking routine" in the satellite connection prior to transmission. An example of an XTP 

system to provide a transparent TCP connection to an end protocol has been described herein, but should not limit the 

user. The satellite system can be similar to the one described scope of the claims. Any suitable satellite protocol can be 

herein, but is not limited. The present process begins at start, 60 used according to certain embodiments of the present inven- 

step 301. In a specific embodiment, a plurality of connec- tion. If the destination address of the TCP packet is config- 

tions are provided. In particular, the present process provides ured to be converted to the XTP protocol format, then the 

a first connection, step 303. The first connection is a TCP packet is converted into the XTP protocol in a step 331. 

connection between a client and a client side gateway, which Otherwise, the packet is transmitted in its TCP format via an 

interfaces to a satellite link. The present process provides a 65 alternative branch to step 327. By way of the present 

second connection, step 305, which provides a connection decisional process, the present invention is useful for sites 

between the client side gateway and a destination gateway where a single satellite gateway communicates with multiple 
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remote sites, some of which have gateways that are com- in a specific embodiment according to the present invention, 

patible with XTP protocol while other sites do not contain This diagram is merely an example which should not limit 

corresponding gateways. Additionally, the present invention the scope of the claims herein. One of ordinary skill in the 

allows specific addresses to be configured for protocol art would recognize other variations, modifications, and 

translation and other addresses to be configured for no 5 alternatives. FIG. 3C shows a first decisional step 341 of 

translation, based on policy decisions of the network admin- determining whether queues are empty when an incoming 

istrator. packet arrives. In a presently preferable embodiment, there 

In a specific embodiment, the present invention also are two queues, one for queuing high priority (HIPR1) traffic 

provides a rate control step (step 327). In a step 327, and one for queuing "normal" traffic. A person of ordinary 

processing is performed to maintain a suitable or predeter- 10 skill in the art can appreciate that the number of queues can 

mined data rate over the satellite device. The processing of be extended or reduced by straightforward extensions of the 

step 327 may require buffering of packets in order to avoid methods according to the present invention. If the queues are 

overloading the satellite link, such as 105 and 103 in FIG. 1. empty, then processing continues with a decisional step 343. 

This can be accomplished using the process depicted by Otherwise, processing continues with a decisional step 345. 

FIGS. 3C-3D, but is not limited to this process. Then, in a 15 Decisional step 343 determines whether the current sys- 

step 329, the packet is transmitted along a connection tem clock tick count is the same as a stored clock tick count, 

established between transmitted from the sending satellite If the system clock tick and the stored clock tick are the 

gateway across the satellite link. Then, in a step 333, the same, then processing continues with decisional step 349, 

packet is converted back to TCP, if it was converted to XTP which determines whether a byte counter and a length of an 

protocol in step 331. Then, in a step 335, the packet is routed 20 incoming packet are greater than a predetermined 

to its remote destination. The present method is especially maximum, based on the desired transmission rate, denoted 

useful for sites where a single satellite gateway communi- here as "MAX". If the maximum would not be exceeded, 

cates with multiple remote gateways, some of which are then processing continues with step 355, in which the packet 

compatible with XTP protocol while others of the remote is sent and the byte counter is incremented by the packet 

gateways are not. Some configurations may have multiple 25 length. Otherwise, if the maximum would be exceeded in 

remote sites per satellite gateway. Some of these remote sites step 349, then processing continues with a step 357, in which 

may have a satellite gateway installed, while others do not. the difference between MAX and the current value of the 

Thus, there may be no satellite gateway on the remote side, byte counter is stored as "EXTRA", and a timer can be 

just a IP routing configuration. The process completes rout- started. Processing then continues at step 345. Otherwise, if 

ing (step 335) when the information enters a destination 30 step 343 determines that the clock tick and stored clock tick 

server 131, which transfers the information to a destination are different, processing continues with a step 347 in which 

client. The process stops (step 337) when the connection is a byte counter is cleared and the stored clock tick is updated, 

terminated. Processing then continues with a step 355, as described 

In a particular embodiment according to the present above, 
invention, TCP connections at times pass a piece of infor- 35 If decisional step 341 determines that at least one of the 
mation in the protocol header which must be delivered as queues is not empty, or if the packet length would have 
soon as possible to the destination side of the connection. increased the byte counter beyond MAX in step 349, then in 
This piece of information is known as the "urgent pointer". a decisional step 345, a determination is made whether the 
In select embodiments, the TCP implementation that is part incoming packet is a retransmission. If the packet is a 
of the client-side satellite gateway, such as for example 40 retransmission, then in a step 351, the packet is added to the 
satellite gateway 203 of FIG. 2, can extract this urgent high priority (HIPRI) queue. Otherwise, in a step 353, the 
pointer from the TCP header. However, this operation is not packet is added to the normal queue, 
required by the system of FIG. 2 and is not intended to limit FIG. 3D illustrates a simplified flowchart of a timer 
the scope of the claims. ATCP module, such as TCP module service process useful in conjunction with data rate control 
229 of FIG. 2, for example, can extract the urgent pointer 45 process illustrated by FIG. 3C in a specific embodiment 
and pass it to a satellite gateway translation module, which according to the present invention. This diagram is merely 
can be satellite gateway translation module 231 of FIG. 2, or an example which should not limit the scope of the claims 
an equivalent. The urgent pointer is passed down to a herein. One of ordinary skill in the art would recognize other 
satellite protocol module, such as satellite protocol module variations, modifications, and alternatives. FIG. 3D shows a 
233 of FIG. 2, or an equivalent. The urgent pointer can then 50 step 361 invoked whenever a timer set in step 357 expires, 
be carried in the satellite protocol header to a satellite In step 341, the byte counter is cleared and the local 
gateway, such as satellite gateway 205 of FIG. 2, or any maximum is set to the maximum MAX added to EXTRA, 
other receiving satellite gateway. At the receiving satellite Then, in a decisional step 363, the high priority (HIPRI) 
gateway, the urgent pointer can be extracted by a satellite queue is checked to determine whether packets are on the 
protocol module, such as satellite protocol module 247 of 55 queue. If there are packets on the HIPRI queue, then 
FIG. 2, and passed up to a translation module, such as processing continues with a decisional step 365. Otherwise, 
translation module 249, or another satellite translation processing continues with a decisional step 367. 
module, which can deliver it to a TCP module, such as TCP If there are packets on the HIPRI queue, then in a 
module 251. The TCP module then incorporates the urgent decisional step 365, a determination is made whether the 
pointer in its target field in the TCP header for immediate 60 byte counter and the packet length are less than a local 
delivery to an end server, such as end server 207. This maximum. If this is indeed the case, then processing con- 
header for delivery to the server refers to the point in the data tinues with a step 369 in which the packet is dequeued from 
stream that has not yet arrived at the second satellite gateway the HIPRI queue and sent. Also, the byte counter is incre- 
machine. In some embodiments, appropriate urgent pointer mented to reflect the length of the data in the packet, 
processing can alleviate malfunctions. 65 Otherwise, if decisional step 365 determines that the byte 

FIG. 3C illustrates a simplified flowchart of a data rate counter and the packet length exceed the local maximum, 

control process such as data rate control step 327 in FIG. 3B then in a step 371 the timer is restarted and processing 
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returns to the invoking process. Processing can continue 100 Kbps when the round trip time was 540 ms. As the test 

when the timer expires. data in FIG. 4 show, even clients with a 32 KB window were 

If decisional step 363 determines that there are no packets able to reach a throughput of a mere 400 Kbps. The present 

on the HIPRI queue, then processing continues with a system allowed the client to take advantage of the available 

decisional step 367. Decisional step 367 determines whether 5 bandwidth regardless of the window size of the client or 

there are packets on the normal queue. If there are no packets server. 

on the normal queue, then processing continues with a step In an alternative experiment, a "Round Trip Delay" was 

375, in which the current clock tick is stored in a global cell. analyzed against "Throughput," as shown in a simplified 

Otherwise, if decisional step 367 determines that packets are diagram 500 of FIG. 5, for example. This diagram is merely 

on the normal queue, then processing continues with a 10 an example and should not limit the scope of the claims 

decisional step 373, in which a determination is made herein. One of ordinary skill in the art would recognize other 

whether the byte counter and the packet length are less than variations, modifications, and alternatives. Here, the present 

the local maximum. If this is indeed the case, then process- invention removed the dependency of TCP on the round trip 

ing continues with a step 377, in which the packet is time of the network. Performance was measured over sym- 

dequeued from the normal queue and sent. Also, the byte 15 metric 2 Mbps and 10 Mbps links with no errors. These 

counter is incremented to reflect the length of the data in the results illustrate that TCP is able to fully saturate terrestrial 

packet. Otherwise, if decisional step 373 determines that if low-delay networks, but as the delay increases, TCP perfor- 

the byte counter and the packet length exceed the local mance dropped rapidly. In contrast, a network which used 

maximum, then in a step 379 the timer is restarted and the present system was able to maintain broad near complete 

processing returns to the invoking process. Processing can 20 usage of the link regardless of the round trip time of the 

continue when the timer expires. network. 

FIG. 3E illustrates a representative system overview in a In an alternative experiment, a "Bit Error Rate" was 
particular embodiment according to the present invention. monitored against "Throughput," which is shown by the 
This diagram is merely an example which should not limit simplified diagram 600 of FIG. 6, for example. This diagram 
the scope of the claims herein. One of ordinary skill in the 25 is merely an example and should not limit the scope of the 
art would recognize other variations, modifications, and claims herein. One of ordinary skill in the art would recog- 
alternatives. A client 380 initiates a connection request to a nize other variations, modifications, and alternatives. Net- 
TCP server 388. Satellite gateway 384 intercepts the con- works which incorporated the present invention were also 
nection request and establishes a second connection 385 sensitive to the bit error rate of the link. The diagram shows 
with a second Satellite gateway 386. The second satellite 30 throughput as a function of the bit error rate for a symmetric 
gateway 386 then initiates a third connection 387 with the 10 Mbps satellite network with a 540 ms round trip time and 
server 388. Once connection 387 is established and that a TCP window size of 1 MB. Even at low error rates, TCP 
information has been communicated back to the satellite was able to deliver a mere 1.2 Mbps. At an error rate of 
gateway 384, the first TCP connection 383 can be confirmed l.OxlO" 5 , TCP's throughput dropped to 0.05 Mbps. A net- 
between the client 380 and satellite gateway 384. Although 35 work which used the present system was able to fully 
depicted in terms of satellite and satellite gateways, the saturate the link at low error rates and delivered 2.7 Mbps 
present invention can also be embodied in other forms of even at an error rate of 1.0xl0" s . 

network hardware. For example, first gateway 384 and While the above is a full description of the specific 

second gateway 386 can be connected by a wireless network embodiments, various modifications, alternative construc- 

and the like. 40 tions and equivalents may be used. For example, the above 

Although the above has generally described the present has generally been described in terms of using XTP as a 

invention according to specific systems and methods, the satellite protocol. Other types of protocols may be available, 

present invention has a much broader range of applicability. For example, the protocol can include a modified TCP or the 

In particular, the present invention is not limited to satellite like. Therefore, the above description and illustrations 

telecommunications, but can be applied to any networking 45 should not be taken as limiting the scope of the present 

situation where an improved or optimized protocol is desired invention which is defined by the appended claims, 

for use over a specific portion of the network, and the end What is claimed is: 

systems cannot be updated to use the improved protocol. 1. A communication method for transmitting information, 

Thus, in some embodiments, satellite gateways could pro- said information comprising a plurality of packets, each of 

vide access to wireless or cabled networks and internetworks 50 said packets comprising data and a header, in a system 

of all kinds. Of course, one of ordinary skill in the art would comprising a client, selected from a plurality of potential 

recognize other variations, modifications, and alternatives. clients; 

Experiment a server, selected from a plurality of potential servers; 

To prove the principles and operation of the present a fifst connected to said client by a first tele- 

system, experiments have been performedMn the present 55 communications link; 

experiments, we ran a series of single-client KI P file transfer , A . , , 

throughput tests to compare performance of conventional a s ™ nd gateway, connected to Sai d server by a second 

TCP and the present invention over a wide variety of telecommunications link; 

different TCP windows sizes, link bandwidths, round trip a thu " d telecommunications link connecting said first 

delay times, and bit error rates. In one experiment, "Widow eo gateway to said second gateway, said method compris- 

Size" was compared against "Throughput", as shown by the m & 

simplified diagram 400 of FIG. 4, for example. This diagram intercepting a transport connection attempt with said 

is merely an example and should not limit the scope of the server, said transport connection attempt initiated by 

claims herein. One of ordinary skill in the art would recog- said client; 

nize other variations, modifications, and alternatives. With- 65 establishing a transport connection between said first 

out performance enhancements or TCP window size tuning, gateway and said second gateway over said third tele- 

most clients were limited to a throughput rate of less than communications link; 
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converting a flow of information from a first transport 
protocol into a second transport protocol at the first 
gateway for transmission over the third telecommuni- 
cations link; 

converting the flow of information from the second trans- 5 
port protocol into the first transport protocol at the 
second gateway for transmission over the second tele- 
communications Link; 

wherein said first and second gateways are each adapted 
for converting the flow of information from the first 10 
transport protocol into the second transport protocol, 
and also from the second transport protocol into the 
first transport protocol; and 

wherein said converting at the first gateway occurs trans- 
parendy to said client. ^ 

2. The method of claim 1 further comprising: 
converting a return flow of information at said second 

gateway from the first transport protocol into the sec- 
ond transport protocol for transmission over said third 
telecommunications link; and 20 
converting said second transport protocol into said first 
transport protocol at said first gateway for transmission 
to the client. 

3. The method of claim 2 wherein the first transport 
protocol comprises TCP and the second transport protocol 25 
comprises XTR 

4. The method of claim 2 wherein said second transport 
protocol is more suitable for transmission over a satellite 
link than TCP. 

5. The method of claim 2 wherein said converting com- 30 
prises removing said header to leave said data substantially 
intact. 

6. The method of claim 2 wherein said converting com- 
prises removing said header to leave said data substantially 
intact and encapsulating said data using a second header. 35 

7. The method of claim 6 wherein said data is a portion of 
said flow of information. 

8. The method as in claim 1 wherein said converting at 
said first gateway occurs transparently to said server. 

9. The method as in claim 1 wherein said converting at 40 
said second gateway occurs transparently to said client. 

10. The method as in claim 1 wherein said converting at 
said second gateway occurs transparently to said server. 

11. The method as in claim 1 wherein the first and second 
gateways comprise protocol gateways adapted for convert- 45 
ing the flow of information from the first transport protocol 
into the second transport protocol for improved transmission 
characteristics over the third telecommunications link, and 
wherein both the first and second transport protocols are 
capable of transmission over the third telecommunications 50 
link. 

12. The method as in claim 1 wherein the client comprises 
the first gateway, and wherein said converting at the first 
gateway occurs at the client. 

13. The method as in claim 1 wherein the first and second 55 
gateways comprise substantially identical protocol conver- 
sion functionality relative to each other. 

14. The method as in claim 1 wherein the end-to-end 
semantics are substantially maintained between the client 
and the server. 60 

15. The method as in claim 1 wherein the transport 
connections between the client and the first gateway, 
between the first and second gateways, and between the 
second gateway and the server define a 1:1:1 connection 
relationship. 65 

16. The method as in claim 1 wherein the transport 
connection between the first and second gateways comprises 
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a separate connection dedicated to the transport connection 
attempt initiated by the client. 

17. The method as in claim 1 further comprising: 
intercepting a second transport connection attempt with 

the server, the second transport connection attempt 
initiated by a second client, and 
establishing a second transport connection between the 
first and second gateways over the third telecommuni- 
cations link, the second transport connection being 
independent from the transport connection. 

18. The method as in claim 1 further comprising inter- 
cepting a second transport connection attempt with the 
server, and establishing a separate transport connection 
between the first and second gateways to be associated with 
the second transport connection attempt. 

19. The method as in claim 1 further comprising: 
extracting an urgent pointer from at least one of the packet 

headers in the first transport protocol; 
incorporating the urgent pointer into a packet header in 

the second transport protocol for transmission over the 

third telecommunications link; 
extracting the urgent pointer from the packet header in the 

second transport protocol; and 
incorporating the urgent pointer into the packet header io 

the first transport protocol. 

20. The method as in claim 1 wherein the first gateway 
comprises a rate control module. 

21. The method as in claim 20 wherein the rate control 
module is adapted for determining whether a packet in the 
flow of information can be transmitted immediately over the 
third telecommunications link or be queued for later trans- 
mission. 

22. A communication method comprising: 
intercepting a first communication connection between a 

client and a server; 

forming a second communication connection between a 
first satellite gateway and a second satellite gateway 
that is over a satellite link; 

transmitting information describing said first connection 
to said second satellite gateway; and 

forming a third communication connection between said 
second satellite gateway and a destination server using 
said information describing said first connection 
wherein said forming said second connection and form- 
ing said third connection occurs transparently to said 
client and said server; 

wherein said first and second gateways are substantially 
symmetrical to one another in a transport protocol 
conversion functionality; and 

where said first, second and third communication connec- 
tions define a 1:1:1 connection relationship, 

23. The method of claim 22 wherein said information 
comprises a client address and a destination server address. 

24. The method of claim 22 further comprising transmit- 
ting a response from said second satellite gateway to said 
first satellite gateway when said third communication con- 
nection with said destination server occurs. 

25. The method of claim 22 further comprising transmit- 
ting a response from said first satellite gateway to said client 
when said third communication connection with said desti- 
nation server occurs. 

26. The method of claim 22 further comprising transmit- 
ting a failure response from said first satellite gateway to 
said client when said third communication connection is 
lost. 
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27. The method as in claim 22 wherein the client com- 
prises the first satellite gateway, and wherein said intercept- 
ing the first communication connection occurs at the client. 

28. The method as in claim 22 wherein intercepting the 
first communication connection comprises intercepting a 5 
first transport communication connection. 

29. The method as in claim 22 wherein the first and third 
communication connections comprise a first transport 
protocol, and the second communication connection com- 
prises a second transport protocol. 10 

30. The method as in claim 9 wherein the end-to-end 
semantics are substantially maintained between the client 
and the server. 

31. A communication method comprising: 

intercepting a first communication connection between a 15 
client and a server; 

forming a second communication connection between a 
first satellite gateway and a second satellite gateway 
that is over a satellite link; 

transmitting information describing said first connection 
to said second satellite gateway; 

forming a third communication connection between said 
second gateway and a destination server using said 
information describing said first transport connection ^ 
wherein said forming said second transport connection 
and forming said third transport connection occurs 
transparently to said client and said server; and 

wherein said first and second gateways are substantially 
symmetrical to one another in a transport protocol 30 
conversion functionality. 

32. A communication method comprising: 
intercepting a first communication connection between a 

client and a server; 

forming a second communication connection between a 35 
first satellite gateway and a second satellite gateway 
that is over a satellite link; 

transmitting information describing said first connection 
to said second satellite gateway, wherein said informa- 
tion comprises a client address and a destination server 40 
address; and 

forming a third communication connection between said 
second satellite gateway and a destination server using 
said information describing said first connection 
wherein said forming said second connection and form- 45 
ing said third connection occurs transparently to said 
client and said server, and wherein the end-to-end 
semantics are substantially maintained between the 
client and the server. 

33. The method as in claim 32 further comprising sending 50 
an acknowledgment to the client after forming the third 
communication connection. 

34. A communication method comprising: 
intercepting a first communication connection between a 

client and a server; 

forming a second communication connection between a 
first satellite gateway and a second satellite gateway 
that is over a satellite link; 

transmitting information describing said first connection g 0 
to said second satellite gateway, and 

forming a third communication connection between said 
second satellite gateway and a destination server using 
said information describing said first connection 
wherein said forming said second connection and form- 65 
ing said third connection occurs transparently to said 
client and said server; and 
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transmitting a response from said first satellite gateway to 
said client when said third communication connection 
with said destination server occurs. 

35. The method as in claim 34 wherein transmitting the 
response comprises transmitting an acknowledgement to the 
client after the third communication connection with the 
destination server occurs. 

36. The method as in claim 34 further comprising sub- 
stantially maintaining an end-to-end semantics between the 
client and the server. 

37. A communication method comprising: 
intercepting a first transport communication connection 

between a client and a server; 

forming a second transport communication connection 
between a first gateway and a second gateway that is 
over a telecommunications link; 

transmitting information describing the first transport 
connection to the second gateway; 

forming a third transport communication connection 
between the second gateway and the server using the 
information describing the first transport connection, 
wherein forming the second and third transport con- 
nections substantially maintains the end-to-end seman- 
tics between the client and the server. 

38. The method as in claim 37 wherein the first and third 
transport communication connections comprises a first 
transport layer protocol, and the second transport commu- 
nication connection comprises a second transport layer 
protocol. 

39. The method as in claim 37 wherein the telecommu- 
nications link comprises a satellite link. 

40. A communication method for transmitting 
information, the information comprising a plurality of 
packets, each of the packets comprising data and a header, 
in a system comprising: 

a first gateway connected to a client by a first telecom- 
munications link; 
a second gateway connected to a server by a second 

telecommunications link; and 
a third telecommunications link connecting the first gate- 
way to the second gateway, the method comprising: 
intercepting a connection attempt with the server, the 

connection attempt initiated by the client; 
establishing a first transport connection between the 
first gateway and the second gateway over the third 
telecommunications link; 
determining using a rate control module whether at 
least one of the packets can be transmitted immedi- 
ately over the third telecommunications link or he 
queued for later transmission; 
converting a flow of information from a first transport 
protocol into a second transport protocol at the first 
gateway for transmission over the third telecommu- 
nications link; and 
convening the flow of information from the second 
transport protocol into the first transport protocol at 
the second gateway for transmission over the second 
telecommunications link. 

41. The method as in claim 40 wherein the first gateway 
comprises the rate control module. 

42. The method as in claim 40 further comprising: 
extracting an urgent pointer from at least one of the packet 

headers in the first transport protocol; 
incorporating the urgent pointer into a packet header in 
the second transport protocol for transmission over the 
third telecommunications link; 
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extracting the urgent pointer from the packet header in the 

second transport protocol; and 
incorporating the urgent pointer into the packet header in 

the first transport protocol. 

43. The method as in claim 40 further comprising inter- 
cepting a second connection attempt with the server and 
establishing a second transport connection between the first 
and second gateways that is independent from the first 
transport connection. 

44. The method as in claim 43 wherein the second 
connection attempt is initiated by a second client. 
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45. The method as in claim 40 wherein the end-to-end 
semantics are substantially maintained between the client 
and the server. 

46. The method as in claim 40 wherein the first and 
second gateways are each adapted for converting the flow of 
information from the first transport protocol into the second 
transport protocol, and also born the second transport pro- 
tocol into the first transport protocol and wherein said 
converting at the first gateway occurs transparently to the 
client. 
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wherein said first and second satellite gateways are substantially symmetrical to 
one another in a transport protocol conversion functionality; and 

wherein said first, second and third communication connections define a 1:1:1 
connection relationship. 
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Line 11, should read, 30. The method as in claim 22 wherein the end-to-end 
Lines 14-22, should read, 

31. A communication method comprising: 

intercepting a first transport communication connection between a client and a 

server; 

forming a second transport communication connection between a first gateway 
and a second gateway that is over a telecommunications link; 

transmitting information describing said first transport connection to said 
second gateway; 

forming a third transport communication connection between said second 



Signed and Sealed this 
Seventh Day of October, 2003 




JAMES E. ROGAN 
Director of the United States Patent and Trademark Office 



10/08/2003, EAST Version: 1.04.0000 



DOCUMENT-IDENTIFIER: US 6584083 Bl Page 1 of 9 

US-PAT-NO: ' 6584083 
DOCUMENT- IDENTIFIER: US 6584083 Bl 

TITLE: Internet over satellite method 



Abstract Text - ABTX (1) : 

According to the present invention a telecommunications method for providing 
transport of packetized information over large distances. The method includes 
providing a bi-directional flow of information using a connection over a 
satellite network. The method uses a gateway, which translates the information 
using the TCP protocol into information using a satellite protocol, which is 
suitable for transmission of such information over the satellite network. 

Brief Summary Text - BSTX (2) : 

The present invention relates to telecommunication techniques. More 
particularly, the present invention provides a technique including a method for 
transmitting information using a TCP connection over a satellite system for use 
in a wide area network of computers such, as the Internet. The present method 
provides a high speed and quality transmission of signals to a distant location 
over a satellite system using an Xpress Transport Protocol (herein "XTP") 
protocol, for example. But it will be recognized that the invention has a much 
wider range of applicability; it can also be applied to a private bridged 
network, terrestrial wireless network links, and the like. 

Brief Summary Text - BSTX (9) : 

From the above, it is seen that a more efficient way of transporting 
Internet services over large geographical regions using wireless communication 
media is highly desirable. 

Brief Summary Text - BSTX (11) : 

According to the present invention, a technique for improving TCP 
performance over a wireless wide area network is provided. In an exemplary 
embodiment, the present invention provides a method for converting information 
using a TCP connection to an Xpress Transport Protocol (herein "XTP") 
connection, for example, which is more suitable for transmission over a 
wireless network system such as a satellite system. 

Brief Summary Text - BSTX (12) : 

In a specific embodiment, the present invention provides a communication 
method for transmitting information over a satellite link. The method includes 
providing a bi-directional flow of information, which has data and a header, 
using a TCP connection. As merely an example, the bi-directional flow of 
information can be from the Internet or internet-like network of computers or 
any network using TCP/IP protocols. The method also includes converting the 
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information/ using the TCP connection, into a satellite protocol for 
transmission over a satellite link. The satellite protocol has suitable 
characteristics for transmission of such information over a satellite link. The 
protocol can include, among others, XTP, XTP-like protocols, and the like. 

Detailed Description Text - DETX (3) : 

According to the present invention, a technique for providing a TCP 
connection over a wide area wireless network is provided. In an exemplary 
embodiment, the present invention provides a method for converting information 
using a TCP connection to an XTP connection, which is more suitable for 
transmission over a wireless network system such as a satellite system. Details 
of the present method are described throughout the present specification and 
more particularly below. 

Detailed Description Text - DETX (7) : 

In a specific embodiment, satellite gateway 111A intercepts a TCP connection 
from a client and converts data 105 to a satellite protocol for transmission 
over satellite 101. The gateway 111A also couples through satellite modem 109A, 
which transmits data to satellite 101. The satellite gateway 111B on the 
opposite side of the satellite link translates the data in the satellite 
protocol back to TCP for communications with the server 131. In a specific 
embodiment, the present method provides improved performance over conventional 
techniques. Additionally, the present method remains substantially transparent 
to an end user and is fully compatible with the Internet or an internet 
infrastructure. In many, if not all aspects, no substantial changes are 
required to the client or server. In preferred embodiments, applications 
continue to function without substantial hardware and/or software 
modifications . 

Detailed Description Text - DETX (41) : 

From the physical connection 221, the information traverses to the gateway 
203. The gateway has a physical layer 223, which interacts with driver 225. The 
gateway also includes a networking layer 227 and a transport layer 229, which 
is coupled to a translation module 231. The networking layer 227 determines 
whether the information can be routed over the satellite protocol. If so, the 
data is passed up to the transport layer 229. If not, the data is immediately 
forwarded out to the rate control module 234 for delivery to the satellite link 
239 in non - translated form. The translation module 231 converts the information 
into a satellite protocol 233, which is suitable for use over a satellite link, 
A rate control module 234 determines whether the information can be passed 
immediately to the satellite connection or be queued for later delivery. The 
satellite connection is coupled to a physical layer 237 by a driver 235, which 
transmits information to and from satellite 209. The information traverses to 
and from the satellite in a wireless medium, 239, 241. 

Detailed Description Text - DETX (42) : 

Information is received by the satellite gateway 205, which includes 
multiple, layers, physical and others. The physical layer 243 couples to driver 



http://127.0.0J:4343/C:/APPS/EAST^^ 10/8/03 



DOCUMENT-IDENTIFEER: US 6584083 B 1 Page 3 of 9 

245. The networking and transport layer include a satellite protocol 247 and a 
rate control 244. The network and transport layers connect to a session layer 
which comprises translation module 249. The translation module converts the 
information using the satellite protocol back to TCP/IP. The information 
traverses through the transport layer (i.e., TCP) 251 and the networking layer 
(i.e., IP) 253. Information from the satellite gateway 205 enters a physical 
layer 257 through driver 255. The driver transmits the information to a server 
207 over telecommunications link 259. Driver 255 can also receive information 
from server 207 in the backward path. 

Detailed Description Text - DETX (45) : 

In a specific embodiment, the translation module converts information using 
a TCP connection to a suitable connection for transmission over a satellite 
system. The suitable connection for the satellite is generally resilient to 
transmission over a wireless network such as a satellite network, e.g., Orion 
Worldcast . TM. PanAmSat.TM. Spotbytes . TM. services, and the like. The connection 
should also be suitable for long latency, high loss, and asymmetric bandwidth 
conditions. The connection should also be transparent to the end user at the 
client or server location. The long latency is typically about 200 milliseconds 
to about 700 milliseconds per satellite hop but is not limited to such values. 

Detailed Description Text - DETX (4 6) : 

In a specific embodiment, the present translation module converts 
information using a TCP connection into an XTP, modified TCP or XTP-like 
protocol for transmission over a satellite link, which is illustrated by FIG. 
2A, for example. Here, the TCP module receives information 350 including the 
TCP connection. The information includes data 333, a TCP header 335, and an IP 
header 337. The TCP module removes the TCP header from the information such 
that the information 351 includes substantially all data 333 and passes the 
data, along with certain TCP header information, to the translation module. The 
translation module passes the data or portions of data to the satellite 
protocol module where a satellite protocol header 339 is prepended onto the 
data. The header is an XTP header or like. The information 352 now includes the 
XTP header, which is suitable for transmission over the satellite link. 
Depending on the specific implementation, the XTP header and data may also be 
prepended with an IP header for transmission over the satellite link. In 
particular, the information is transferred to the physical layer and the 
driver. The driver and physical layer send the information to a receiving 
satellite gateway, which may prepend additional headers. 

Detailed Description Text - DETX (47) : 

From the satellite link, the information including the XTP header enters a 
receiving XTP module. The receiving XTP or satellite protocol module removes 
the XTP header from the information, leaving data 353. The receiving satellite 
protocol module passes the data to the translation module, which can be a 
routing module used to route data to the proper protocol. The translation 
module then passes the data to the TCP module. The receiving TCP module 
attaches a TCP header 343 and IP header 341 onto the data to form information 
that is now ready for transmission over a network to a receiving server 
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destination: The information using the TCP connection traverses through a 
network to the destination server. 



Detailed Description Text - DETX (48) : 

In other embodiments, the translation module can also convert a portion of 
the information including the data and TCP/IP headers to information using the 
XTP protocol. Alternatively, the translation module can convert more than one 
segment of information including multiple TCP/IP headers into a single piece of 
information including the XTP header for transmission over a satellite link. 
Depending upon the application, the translation module can convert the 
information including the TCP connection into any one or any combination of the 
above. Further details of these methods, and others, are described in more 
detail below. 

Detailed Description Text - DETX (4 9) : 

FIGS. 3A and 3B are simplified diagrams of process diagrams according to 
embodiments of the present invention. These diagrams are merely illustrations 
and should not limit the scope of the claims herein. One of ordinary skill in 
the art would recognize other variations, modifications, and alternatives. In a 
specific embodiment, the present invention uses a connection process 300, which 
is illustrated by FIG. 3A. The connection process uses a plurality of separate 
connections using a "handshaking routine" in the satellite system to provide a 
transparent TCP connection to an end user. The satellite system can be similar 
to the one described herein, but is not limited. The present process begins at 
start, step 301. In a specific embodiment, a plurality of connections are 
provided. In particular, the present process provides a first connection, step 
303. The first connection is a TCP connection between a client and a client 
side gateway, which interfaces to a satellite link. The present process 
provides a second connection, step 305, which provides a connection between the 
client side gateway and a destination gateway over a wireless (e.g., satellite) 
link. The connection between the wireless link can be any suitable connection 
such as XTP or XTP-like connection. The present process provides a third 
connection, step 307, which forms a TCP connection between the destination 
gateway to the destination server, which can traverse through the Internet or 
an internet. Once these connections have been made they are maintained, step 
309. The present process ends at stop 311, which terminates all three 
connections . 

Detailed Description Text - DETX (52) : 

FIG. 3B illustrates a simplified flowchart of a novel routing process 320 in 
a specific embodiment according to the present invention that begins with a 
starting step 321. This diagram is merely an example which should not limit the 
scope of the claims herein. One of ordinary skill in the art would recognize 
other variations, modifications , and alternatives . In a step 323, a client host 
sends a TCP packet destined for a particular IP address to a satellite gateway. 
In an example, the satellite gateway can be similar to the one 111A described 
above, but can also be others. In a decisional step 325, the satellite gateway 
receives the packet and determines whether the packet is to be carried over an 
XTP connection prior to transmission. An example of an XTP protocol has been 
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described herein, but should not limit the scope of the claims. Any suitable 
satellite protocol can be used according to certain embodiments of the present 
invention. If the destination address of the TCP packet is configured to be 
converted to the XTP protocol format, then the packet is converted into the XTP 
protocol in a step 331. Otherwise, the packet is transmitted in its TCP format 
via an alternative branch to step 327. By way of the present decisional 
process, the present invention is useful for sites where a single satellite 
gateway communicates with multiple remote sites, some of which have gateways 
that are compatible with XTP protocol while other sites do not contain 
corresponding gateways. Additionally, the present invention allows specific 
addresses to be configured for protocol translation and other addresses to be 
configured for no translation, based on policy decisions of the network 
administrator . 

Detailed Description Text - DETX (53) : 

In a specific embodiment, the present invention also provides a rate control 
step (step 327) . In a step 327, processing is performed to maintain a suitable 
or predetermined data rate over the satellite device. The processing of step 
327 may require buffering of packets in order to avoid overloading the 
satellite link, such as 105 and 103 in FIG. 1. This can be accomplished using 
the process depicted by FIGS. 3C-3D, but is not limited to this process. Then, 
in a step 329, the packet is transmitted along a connection established between 
transmitted from the sending satellite gateway across the satellite link. Then, 
in a step 333, the packet is converted back to TCP, if it was converted to XTP 
protocol in step 331. Then, in a step 335, the packet is routed to its remote 
destination. The present method is especially useful for sites where a single 
satellite gateway communicates with multiple remote gateways, some of which are 
compatible with XTP protocol while others of the remote gateways are not. Some 
configurations may have multiple remote sites per satellite gateway. Some of 
these remote sites may have a satellite gateway installed, while others do not. 
Thus, there may be no satellite gateway on the remote side, just a IP routing 
configuration. The process completes routing (step 335) when the information 
enters a destination server 131, which transfers the information to a 
destination client. The process stops (step 337) when the connection is 
terminated. 

Detailed Description Text - DETX (54) : 

In a particular embodiment according to the present invention, TCP 
connections at times pass a piece of information in the protocol header which 
must be delivered as soon as possible to the destination side of the 
connection. This piece of information is known as the "urgent pointer". In 
select embodiments, the TCP implementation that is part of the client-side 
satellite gateway, such as for example satellite gateway 203 of FIG. 2, can 
extract this urgent pointer from the TCP header. However, this operation is not 
required by the system of FIG. 2 and is not intended to limit the scope of the 
claims. A TCP module, such as TCP module 229 of FIG. 2, for example, can 
extract the urgent pointer and pass it to a satellite gateway translation 
module, which can be satellite gateway translation module 231 of FIG. 2, or an 
equivalent. The urgent pointer is passed down to a satellite protocol module, 
such as satellite protocol module 233 of FIG. 2, or an equivalent. The urgent 
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pointer* can 'then be carried in the satellite protocol header to a satellite 
gateway, such as satellite gateway 205 of FIG. 2, or any other receiving 
satellite gateway. At the receiving satellite gateway, the urgent pointer can 
be extracted by a satellite protocol module, such as satellite protocol module 
247 of FIG. 2, and passed up to a translation module, such as translation 
module 249, or another satellite translation module, which can deliver it to a 
TCP module, such as TCP module 251. The TCP module then incorporates the urgent 
pointer in its target field in the TCP header for immediate delivery to an end 
server, such as end server 207. This header for delivery to the server refers 
to the point in the data stream that has not yet arrived at the second 
satellite gateway machine. In some embodiments, appropriate urgent pointer 
processing can alleviate malfunctions. 

Detailed Description Text - DETX (61) : 

FIG. 3E illustrates a representative system overview in a particular 
embodiment according to the present invention. This diagram is merely an 
example which should not limit the scope of the claims herein. One of ordinary 
skill in the art would recognize other variations, modifications, and 
alternatives. A client 380 initiates a connection request to a TCP server 388. 
Satellite gateway 384 intercepts the connection request and establishes a 
second connection 385 with a second Satellite gateway 386. The second satellite 
gateway 386 then initiates a third connection 387 with the server 388. Once 
connection 387 is established and that information has been communicated back 
to the satellite gateway 384, the first TCP connection 383 can be confirmed 
between the client 380 and satellite gateway 384. Although depicted in terms of 
satellite and satellite gateways, the present invention can also be embodied in 
other forms of network hardware. For example, first gateway 384 and second 
gateway 386 can be connected by a wireless network and the like. 

Detailed Description Text - DETX (62) : 

Although the above has generally described the present invention according 
to specific systems and methods, the present invention has a much broader range 
of applicability. In particular, the present invention is not limited to 
satellite telecommunications, but can be applied to any networking situation 
where an improved or optimized protocol is desired for use over a specific 
portion of the network, and the end systems cannot be updated to use the 
improved protocol. Thus, in some embodiments, satellite gateways could provide 
access to wireless or cabled networks and internetworks of all kinds. Of 
course, one of ordinary skill in the art would recognize other variations, 
modifications, and alternatives. 

Claims Text - CLTX (1) : 

1. A communication method for transmitting information, said information 
comprising a plurality of packets, each of said packets comprising data and a 
header, in a system comprising a client, selected from a plurality of potential 
clients; a server, selected from a plurality of potential servers; a first 
gateway, connected to said client by a first telecommunications link; a second 
gateway, connected to said server by a second telecommunications link; a third 
telecommunications link connecting said first gateway to said second gateway, 
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said method* comprising: intercepting a transport connection attempt with* said 
server, said transport connection attempt initiated by said client; 
establishing a transport connection between said first gateway and said second 
gateway over said third telecommunications link; converting a flow of 
information from a first transport protocol into a second transport protocol at 
the first gateway for transmission over the third telecommunications link; 
converting the flow of information from the second transport protocol into the 
first transport protocol at the second gateway for transmission over the second 
telecommunications link; wherein said first and second gateways are each 
adapted for converting the flow of information from the first transport 
protocol into the second transport protocol, and also from the second transport 
protocol into the first transport protocol; and wherein said converting at the 
first gateway occurs transparently to said client. 

Claims Text - CLTX (2) : 

2. The method of claim 1 further comprising: converting a return flow of 
information at said second gateway from the first transport protocol into the 
second transport protocol for transmission over said third telecommunications 
link; and converting said second transport protocol into said first transport 
protocol at said first gateway for transmission to the client. 

Claims Text - CLTX (5) : 

5. The method of claim 2 wherein said converting comprises removing said 
header to leave said data substantially intact. 

Claims Text - CLTX (6) : 

6. The method of claim 2 wherein said converting comprises removing said 
header to leave said data substantially intact and encapsulating said data 
using a second header. 

Claims Text - CLTX (8) : 

8. The method as in claim 1 wherein said converting at said first gateway 
occurs transparently to said server. 

Claims Text - CLTX (9) : 

9. The method as in claim 1 wherein said converting at said second gateway 
occurs transparently to said client. 

Claims Text - CLTX (10) : 

10. The method as in claim 1 wherein said converting at said second gateway 
occurs transparently to said server. 

Claims Text - CLTX (11) : 

11. The method as in claim 1 wherein the first and second gateways comprise 
protocol gateways adapted for converting the flow of information from the first 
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transport protocol into the second transport protocol for improved transmission 
characteristics over the third telecommunications link, and wherein both the 
first and second transport protocols are capable of transmission over the third 
telecommunications link. 

Claims Text - CLTX (12) : 

12. The method as in claim 1 wherein the client comprises the first gateway, 
and wherein said converting at the first gateway occurs at the client. 

Claims Text - CLTX (13) : 

13. The method as in claim 1 wherein the first and second gateways comprise 
substantially identical protocol conversion functionality relative to each 
other . 

Claims Text - CLTX (22) : 

22. A communication method comprising: intercepting a first communication 
connection between a client and a server; forming a second communication 
connection between a first satellite gateway and a second satellite gateway 
that is over a satellite link; transmitting information describing said first 
connection to said second satellite gateway; and forming a third communication 
connection between said second satellite gateway and a destination server using 
said information describing said first connection wherein said forming said 
second connection and forming said third connection occurs transparently to 
said client and said server; wherein said first and second gateways are 
substantially symmetrical to one another in a transport protocol conversion 
functionality; and where said first, second and third communication connections 
define a 1:1:1 connection relationship. 

Claims Text - CLTX (31) : 

31. A communication method comprising: intercepting a first communication 
connection between a client and a server; forming a second communication 
connection between a first satellite gateway and a second satellite gateway 
that is over a satellite link; transmitting information describing said first 
connection to said second satellite gateway; forming a third communication 
connection between said second gateway and a destination server using said 
information describing said first transport connection wherein said forming 
said second transport connection and forming said third transport connection 
occurs transparently to said client and said server; and wherein said first and 
second gateways are substantially symmetrical to one another in a transport 
protocol conversion functionality. 

Claims Text - CLTX (40) : 

40. A communication method for transmitting information, the information 
comprising a plurality of packets, each of the packets comprising data and a 
header, in a system comprising: a first gateway connected to a client by a 
first telecommunications link; a second gateway connected to a server by a 
second telecommunications link; and a third telecommunications link connecting 
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the first gateway to the second gateway, the method comprising: intercepting 'a 
connection attempt with the server, the connection attempt initiated by the 
client; establishing a first transport connection between the first gateway and 
the second gateway over the third telecommunications link; determining using a 
rate control module whether at least one of the packets can be transmitted 
immediately over the third telecommunications link or he queued for later 
transmission; converting a flow of information from a first transport protocol 
into a second transport protocol at the first gateway for transmission over the 
third telecommunications link; and convening the flow of information from the 
second transport protocol into the first transport protocol at the second 
gateway for transmission over the second telecommunications link. 

Claims Text - CLTX (4 6) : 

46. The method as in claim 40 wherein the first and second gateways are each 
adapted for converting the flow of information from the first transport 
protocol into the second transport protocol, and also horn the second transport 
protocol into the first transport protocol and wherein said converting at the 
first gateway occurs transparently to the client. 
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